As programming approaches and foundations have evolved, application programming interfaces (APIs) and programming schemas have been developed to standardize and unify programming methodologies that were previously multi-variant and relatively incompatible. Modem programming therefore often involves employing APIs and schemas in conjunction with reusable libraries. Such Programming languages continue to evolve to facilitate specification by programmers as well as efficient execution.
Compilers and/or interpreters bear the burden of translating high-level logic into executable machine code. In general, a compilers and/or interpreters are components that receive a program specified in a source programming language (e.g., C, C#, Visual Basic, Java . . . ) and covert the logic provided thereby to machine language that is executable by a hardware device. However, the conversion need not be done verbatim. In fact, conventional compilers and/or interpreters analyze the source code and generate very efficient code. For example, programmers write code that sets forth a logical flow of operations that is intuitive and easy for humans to understand, but is often inefficient for a computer to execute. Compilers and/or interpreters can identify inefficiencies and improve program performance at the hardware level by eliminating unnecessary operations and/or rearranging the execution of instructions while still achieving the intended results. In this manner, programmers can create robust and efficient software programs.
Typically for Common Language Runtime (CLR), data types can be value types or reference types. Reference types are variables that are stored on a heap and referenced by a pointer stored on the stack or inside another object in the heap. Value types are variables that are stored directly on the stack. Consequently, variables that are represented as reference types can be uninitialized (termed “null”), but variables that are represented as value types cannot be established in an uninitialized condition without risking indeterminate or even catastrophic results. Put differently, a value type cannot be null because there is always a value, and cannot be expressed as null.
For example, if statically it is known that    Dim X As Nullable (of Int)=Nothing (“Null”)    Dim Y As Nullable (of Int)=5    Dim Z=X+Y 
Z has the type Nullable (of Int) and has a value of nothing, e.g. via three—valued, or null-propagating, logic. Yet, and as will be described in detail infra, such can create problems in late bindings.
Moreover, support for nullability across all types, including value types, is essential when interacting with null supported languages, such as database languages (e.g., SQL). A database language can employ a null value to indicate that the actual data value is unknown or missing. By providing null support within a general purpose programming language null-supported languages and programming languages may be integrated (e.g., code in the C# programming language may read, write or interpret nullable fields in a database language). The nullification problem has been previously addressed with many different strategies. Examples of such strategies include tuples, variants, convoluted pointer manipulations, and boxing. However, each of these strategies has one or more drawbacks.
For example, boxing is an implicit conversion of a value type to the type object or to any interface type implemented by this value type. Put differently, a value type that exists on a stack and obtain a pointer to a heap with a reference. Boxing a value of a value allocates an object instance and copies the value into the new object. Likewise, unboxing is an explicit conversion from the type object to a value type or from an interface type to a value type that implements the interface. An unboxing operation typically consists of: checking the object instance to make sure it is a boxed value of the given value type, and copying the value from the instance into the value-type variable.
Now consider the example of boxing a nullable. Typically, the manner a nullable is implemented is via a structure that has a Boolean and value. This is achieved by automatically creating a multi-element structure including an element for the underlying value and a Boolean element representing whether or not the underlying value is null (e.g., flag indicating null or non-null value for the underlying type). If the Boolean element is declared false for example, the underlying type is considered null, whereas if the Boolean element is true for example, the value contained in the underlying value is considered the value of the nullable type variable.
For example, “nothing” has no value, and/or value can be ignored. As explained earlier, “5” of type nullable can be represented by a pair of boolean, which is not null and has a value of “5”. As such, the implementation for representing a nullable is via a structure that has a boolean and a value. Moreover, considering a scenario of boxing a value “3”, on the heap a reference to the value 3 can be obtained. Likewise, when boxing the value of “true, 5”—it is intuitively expected that there is a pointer to the heap that can contains “true” and 5.
Yet, to box “nothing” and “false”, then an inconsistency occurs, because a reference is created to an actual thing, when in fact the starting point was a “nothing”. For example, the thing that has been referenced to does not represent “nothing” for a reference type. Put differently, the starting point is an empty set, yet the outcome is a set that contains the empty set, and such represents an incorrect out come.
Moreover, in a heap a distinction can be made between a boxed item and an integer, yet a differentiation between “nothing” and the box “nothing” can be made, which is undesirable. Accordingly, if boxing a nullable type is desired (if it is “true” and has a value), such can be removed and boxed in manner wherein the boxing is aware of nullability.
An additional problem exists now that there is no trace that such previously existed as nullable, as the representation of a boxed nullable (int.) is the same as a representation of a boxed int. Accordingly, one cannot distinguish between nullable (of T) and boxed T.
Put differently, reversal with fidelity when moving from a value type to an object via the boxing and vice versa for nullable types cannot be performed, and a distinction is lost. Such can introduce problems for late binding. Referring to the example of:
Dim A As Object=X
Dim B As object=Y—Such assignments cause boxing to occur from nullable to object.
Considering now the late-bound addition of Dim C=A+B, A can represent the no pointer (nothing) and B can be represented by the boxed 5. Yet, it is not known that A and B are nullables. As such, Visual Basic (VB) late bound addition will interpret nothing as zero and return a result of 5 instead of “nothing”, which creates a difference in semantics depending on whether there is an early bound or a late bound. Such inconsistency is problematic and needs to be minimized. Put differently, the overload and compiler can statically resolve the three valued or null propagating logic as the types are known at compile time—yet, for late binding and resolving at runtime the knowledge of nullability is unavailable.
Therefore, there is a need to overcome the aforementioned exemplary deficiencies associated with conventional systems and devices.